Bas點出了我們看到的大部分 scrum master 缺少的部分。
只能說自己的經歷真的算是誤打誤撞，幸運地走出了還蠻上軌道的路。
我過去是個 team leader, 也是tech lead, 但在 scrum 轉型時期，我是預設不領 task 的 lead.
我的主要工作，是跟團隊一起 pair, 從 pair 的過程中把產品品質做好，把團隊技能拉起來，把基礎建設跟團隊規範持續改善，pair 過的就節省 code review 的時間。
其他的工作則是和團隊一位專業的 QA 一起與 PO 進行一場小小的 pre-refinement, 從需求、開發、測試三個維度來看，需求是否已經到 ready 的程度，避免整個 team 的 refinement 時間過長、效益過低，提前抓出技術可行性、產品功能設計的盲點，以及商業價值評估。
我還有其他 5 個機動性的任務：
1. 需要我時，我會協助 PO 一起去跟 stakeholders 說明，或是爭取時間、資源，或是跨 team 的協調工作。
2. 我會觀察線上營運狀態，bug 的類型，緊急程度跟影響範圍。從 bug 的部分往往可以分析出來我們流程還有哪些地方可以改善的。
如果是緊急程度最高的 bug, 而其他人正在忙，我會跳下去處理，讓影響範圍降到最低。
3. 如果臨時有什麼插件需求，我就是 PO 一顆很好用的活棋，我可以從 pair 過程抽出身來，幫他處理這些插件，以解燃眉之急。
4. 系統架構面的設計，整個部門技術選擇的決策，跟各個專案 kickoff 的 reviewer，跨部門團隊合作（例如安全、資料部門、search），推進部門與產品的基礎建設、自動測試、流程開發規範、技術前沿研究、技術教育訓練，也是我在團隊內外的職責。
5. 協助 PO, 因為我們的 PO 當時還算是要兼任 help desk，我們出現過零星幾次，團隊功能做完了，但 PO 還在忙，瓶頸出現在 PO 身上，因為她被線上的營運問題搞得喘不過氣。
我們團隊當時把手上的工作都先暫停，然後跟 PO 盤點一下她現在手上除了放到我們 product backlog 的部分，還有多少事情要處理，有哪一些是會重複發生的。
後來我們針對會重複發生的，要定時觀測的，寫了幾隻報表，設定好 cron job 週期，固定週期就會撈資料寄給 PO, 然後一些快速修正資料的，寫好程式讓她下次處理有介面可以用，而且其他人也可以迅速透過介面幫她處理。
註：還有一點，一開始幾年蠻多人問的，但最近幾年比較少見。
我們的 bug (issue/ticket) 是會排入 product backlog 的。或許是我們的 bug 大部分都會經過 PO, QA 而來，對 PO 來說，她能判斷 bug 的緊急程度，與現在正在進行的 sprint backlog item 何者重要。（別忘了還有我這顆活棋可用）
如果真的就是要當插件進來，我們也會一起討論跟決定，最後還沒領的 item 是否該排出 sprint 挪到下個 sprint 做。
如果大家都認同 插件的必要程度，以及 sprint items 全都不能 miss 在這次是很有意義的，我們就會討論作法的調整（技術債換時間的可能性），或是加班，多點時間消化掉插件的可行性。
喔，對了，我們的 PO 跟 RD 職級是平行的，我們就是一個團隊，大家負責自己的角色職責，榮辱共享。所以沒什麼「壓迫強逼」的問題，一切事情都可以團隊一起商量出來。（當然，我們團隊每個人對產品的 ownership 都很強，就是有問題都會主動跳出來關心發生什麼事，可以怎麼解決那種）
而且我們沒有專屬的 support 團隊或是角色，我們會排 oncall 的，只有農曆過年這種大家可能大部分都出國，手機/網路可能連不上的那種，才需要確保每天都有人可以處理。（這段就是考驗大家的 ownership 了）
那段 scrum 轉型的過程，我們其實並沒有ㄧ個特定的 scrum master 角色，但其實我幹的事情就跟 scrum master 很像（只是少了引導者的部分）。
所以我說挺幸運的，誤打誤撞走出 technical coach 這條職涯路線。再接觸了更多引導相關、Lean、LeSS 之後，就更能擔任 agile coach 的角色。
而 Odd-e 裡面的大部分同事，再加入 Odd-e 之前的經歷，其實也都蠻像的，只是各角色的比重不同而已。
Bas 原文連結：https://less.works/blog/2019/12/05/scrum-master-as-technical-coach.html
Search